<HTML>
<head>
<title>AngelScript: Documentation: Glossary</title>
<LINK rel="stylesheet" type="text/css" href="style.css">
</head>

<body>

<p>
<a href="../index.html">index</a>
</p>

<h1>Documentation: Glossary</h1>

<ul>
<li><a href="#config">Configuration group</a>
<li><a href="#context">Context</a>
<li><a href="#engine">Engine</a>
<li><a href="#module">Module</a>
<li><a href="#handle">Object handle</a>
<li><a href="#section">Section</a>
</ul>

<a name="config"></a>
<h2>Configuration group</h2>

<p>The script library allows the application to register its interface to the scripts in separate configuration groups. Access to these groups can be set on a per script module basis, which means that one script engine can expose different interfaces to different scripts. The configuration groups can also be removed and replaced during the life time of the application.</p>

<a name="context"></a>
<h2>Context</h2>

<p>This is a bad choice of name for this object. It should have been called a 
thread. A context contains the function stack for the currently executing 
function, nothing more.</p>

<p>You can have several context executing in parallel, though only one should 
be active at a time (unless you use multithreading). This means that contexts 
can be suspended and resumed at the will of the application.</p>

<a name="engine"></a>
<h2>Engine</h2>

<p>This the object where the application exposes the interface it wishes the 
scripts to have access to. It is the central object from which all others are 
accessed.</p>

<p>If you want to expose different interfaces to different scripts you should use the configuration groups to define exactly what each script module has access to.</p>

<a name="module"></a>
<h2>Module</h2>

<p>You may think of these as DLLs, if you wish. A module contains a set of 
functions and global variables. The values of the global variables are stored 
in the module, thus are shared between all contexts executing functions from 
that module.</p>

<p>The functions/global vars that a module must contain is defined by the 
application. The script library makes no assumptions, i.e. there is no 
predefined function like 'void main()' that must exist. It depends on what 
you want the application to be able to do.</p>


<a name="handle"></a>
<h2>Object handle</h2>

<p>An object handle is a reference counted pointer to an object. Whenever a handle for an object is stored, the object's reference counter is increased with a call to the object's ADDREF behaviour. When the handle is released the RELEASE behaviour is called. When the object detects that all references have been released it should destroy itself.</p>

<p>Because the handle needs a reference counter to work it is only supported for those object types that have the ADDREF and RELEASE behaviours registered. Primitive types, like int, float, and double, for example do not support object handles.</p>



<a name="section"></a>
<h2>Section</h2>

<p>A section can be thought of as a script file. The section must contain 
complete syntactic units, i.e. you cannot put half of a function in one 
section and the other half in another section. The order in which sections 
are added to the module doesn't matter. All sections in a module share the 
same scope and can thus use functions/global variables declared in other 
sections.</p>

<p>The name of the section, is only used to help the developer localize 
compiler errors, etc. To the script engine, the name doesn't matter, you may 
even use the same for all sections, or no name at all.</p>

<p>Once a module is compiled the script section is removed from the engine. 
Thus to compile the module again, all of the sections has to be added once 
more.</p>





<p><a href="#">top</a></p>

</body></HTML>